SPACE 2/SPACE - Library 2 - Volume 1.iso/magazi~1/226/analog.49/faxman.doc

Text File | 1986-10-31 | 7.7 KB | 123 lines

NOTES ON USING FAX
by Douglas Weir


 The following comments are supplementary to those contained in the magazine.

 FAX is a desk accessory, which means that you should copy it to the disk you
boot from, which contains your other ".ACC" files. FAX works in all three
resolutions. It was developed primarily to be used with "1st_Word" and the
Desktop. Note that ONLY "1st_Word" windows with NO special text styling (e.g.,
italics, underlining, etc.) can be successfully dumped.

 The source code files for FAX are included on the disk. The top level is
contained in "fax.c"; the other routines are entered through the code contained
in "fx.c". To play with it, you need a Megamax C compiler. Compile "fax.c",
then "fx.c". Make a library out of the latter, then link "fax.o" with "acc.l"
and the library you created to get "fax.acc". The compiler will give you lots
of warnings about the use of A5 as a base register in the files "f5.ca" -
"f8.ca" when you compile "fx.c", but you can ignore them. The file "fxcomp.h"
contains the settings of certain switches used to compile the present version
of FAX. "TEST_VER" was used to compile an earlier version which was run as a
TOS application with a command line, for testing. "SC_IMAGE" was a version that
saved the entire screen memory before processing instead of one line at a time.
Change the switch settings at your own risk -- it's been a while since I have.

 When you select FAX from the Accessory menu a small GEM window will appear and
you will be prompted to enter the "spacing". This is a one-digit number that
specifies the amount of extra scan lines inserted between text lines in the
window you wish to dump. The default spacing is 0, which means that the
application is simply using the spacing supplied by the system and no more.
"1st_Word" does this. Ironically, the GEM Desktop inserts two extra scan lines
between each text line, so the value entered in this case is 2.

 The second prompt asks you to enter a "d" for Desktop (if you are dumping a
Desktop window), "1" for "1st_Word", or "l" for Logo. The first two windows are
special cases: not all of the "official" workspace in them is occupied by text.
The Desktop adds a special non-text symbol to the left of subdirectory names
and this portion of the window has to be "trimmed" out of the memory block
inspected by FAX. In the case of "1st_Word" the entire left border is a non-GEM
feature added by the program, while the subtitle area across the top of the
window seems to be handled by application routines and not by GEM -- the
workspace dimensions returned by GEM for a "1st_Word" window include this area,
and they shouldn't. Since there is no way for FAX to learn through system calls
what sort of window it is handling, you have to give it this information.
(Press "return" here for the default setting.)

 The spacing and program prompts are kept separate in case you want to try FAX
on text windows generated by some other application that, perhaps, uses
non-standard spacing. Be warned, however, that windows with other non-standard
"features" unknown to FAX will not dump. Text windows using the system font
(and only the system font) in a strictly "legal" GEM format should present no
problems.

 The reverse-video character cell in a "1st_Word" or Logo window which
represents the cursor is handled by FAX, but in a slightly erratic way. FAX
"recognizes" characters from their bit-mapped images in screen memory by
hashing the character-cell data and using this as a key to a table. If the
cursor cell hashes to an invalid key then the program will try reversing the
image, but if the cell does happen to yield a good key AND there is no
"collision" with other values hashing to the same key, then FAX will assume
that the default ASCII code for that key is correct. In other words, if you
dump a "1st_Word" or Logo window with the cursor positioned over a character,
you may or may not find the correct character printed out in that position.
This is a flaw in the program's design which will be corrected in a later
version. (For any hackers in the audience, the correction needs to be made in
'dump_line' in "f8.ca".)However, it is easy to make sure that the cursor is
positioned over blank space when using FAX, even after you have activated the
accessory. Once the two prompts discussed above have been answered, FAX's
window becomes just like any other GEM window -- or almost. You can move it
around, or you can re-activate the window you intend to dump (FAX meanwhile
becomes an inactive window) and make changes to it. When you are ready to
execute the dump you re-activate FAX if necessary and click on the "close" box
to start the dump. Or if you decide to abort, just click on the "full" box.
During the prompts, you can abort by simply pressing the 'x' key.

 The reverse-video text lines sometimes used by the Desktop are not a problem,
since FAX forces a redraw of the window it is about to dump and this gets rid
of the highlighting. FAX will work with screens whose colors have been altered
through the Control Panel accessory, and it will work on monochrome screens
that have been "reversed".

 When FAX begins execution (after you have closed its window), it hides the
mouse cursor and then starts processing the screen memory, based on what GEM
has told it about the active window and its dimensions. If there is no active
window, FAX simply terminates and restores the mouse cursor. If there is a
delay greater than 2-4 seconds before the dump starts, check to make sure your
printer is switched on. If FAX seems to be taking too long figuring things out
(this could happen if you entered the wrong spacing or didn't tell it about a
"1st_Word" window), you can abort it by pressing any key -- the mouse cursor
should reappear.

 In some cases where an application is using an unusual redraw algorithm to
maintain its windows, you may find that the window you want to dump is not
being redrawn properly after you close the FAX window. If this happens, simply
restart FAX and, this time, move it away from the window you want to dump
before you close it.

 As mentioned, FAX will dump Logo text windows. The situation with ST-BASIC is
not so simple. The "Command" window will dump with a space setting of 1 (one)
and a carriage return for the second prompt, but only if it is the only window
on the screen. This is due to BASIC's redraw "algorithm". Attempts to dump
other (e.g., "List") windows, even when all other windows were closed, were
unsuccessful.

 The actual amount of memory occupied by FAX is a little over 39K bytes. Most
of this is for the GEM windowing routines used for FAX's own window. This part
of FAX is a slightly altered version of "WWX.C" (see the October ST-LOG). There
is one important difference, however. The window has been made small enough so
that its buffer can be declared as a simple 9K-byte array. It seems that just
calling one of the dynamic memory-allocation functions ('calloc()' or
'malloc()') imposes an incredible memory overhead on a program. I tried calling
'calloc()' to assign 0 (zero) bytes to a pointer in a desk accessory demo and
found that the active size of the program increased by 44K (!) bytes. Whether
this is a bug just in the Megamax version of these routines or in the
underlying TOS calls I haven't had time yet to find out, but I suspect the
latter. Of course, the only reason one would want to use these calls in an
accessory is to get around an arbitrary segment-size restriction such as
Megamax's, since you can't "de-allocate" such space back to the system when
you're finished with it. Nevertheless, the moral of this story seems to be:
don't do "dynamic" memory allocation in a desk accessory -- it's REALLY
dynamic.